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(57) Abstract: The invention provides a method and system for establishing or handling a connection between a first and a second 
network element connected to different networks such as GPRS/UMTS and IP-based networks. The connection is established by 
means of at least one third network element such as a SGSN or GGSN arranged in one of the networks. The third network element 
is adapted to send, when receiving information on an establishment of a connection, a request to a fourth network element which 
may be a Call State Control Function (CSCF), a Policy Control Function (PCF), or a Call Processing Server (CPS). The request 
requests permission for establishing a requested type of connection, or requests a check of a connection parameter, and specifies the 
first and/or second network element and/or the connection or connection type to be established. The fourth network element returns 
a response specifying a permission for establishing a connection or connection type, or specifying a connection parameter. (Fig. 1) 
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METHOD AND SYSTEM FOR ESTABLISHING A CONNECTION BETWEEN 

NETWORK ELEMENTS 

5 

FIELD OF THE INVENTION 

The invention relates to a method and system for establishing 
a connection between two or more network elements. The 
10 connection may for example be a VoIP (Voice over Internet 
Protocol) call- The connection may involve e.g. an IP 
telephony layer or network and a GPRS/UMTS-based network 
transporting the call. 



15 

BACKGROUND OF THE INVENTION 



Generally, for properly establishing and handling a 
connection between network elements such as a user equipment, 

20 for instance a mobile terminal, and another user terminal or 
database, etc., one or more intermediate network elements 
such as support nodes are involved. One or more connection 
parameters are used for defining connection characteristics 
such as PDP (Packet Data Protocol) context information, 

25 quality of service (QoS) requested or provided, charging- 
related information such as charging tariff, etc. 

In particular in a case when a connection involves two or 
more networks of different types such as networks using 
30 different transmission protocols, ,e.g. GPRS/UMTS-based 
networks and IP-based networks, problems may occur in 
properly establishing the connection and setting the 
connection parameters. 
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SUMMARY OF THE INVENTION 

The present invention provides a method and system which are 
able to properly establish a connection between network 
5 elements , e.g. arranged in different networks, in an 
advantageous manner, as defined in the attached claims. 

The connection can be properly established or processed, e.g. 

10 for charging purposes, by exchanging request and response 

between the third and fourth network element related to the 
permission for establishing a connection (or connection type 
such as PDP type) , or to a connection parameter such as QoS 
(Quality of Service) so as to ensure correct handling of the 

15 connection. 

The third network element may be a support node, preferably a 
gateway support node whereas the fourth network element may 
be a CSCF or PCF or CPS. The fourth network element may be 
20 part of, or provide, a IP telephony layer. 

In accordance with one of the aspects of the invention, the 
communication happens between the PS (packet-switched) domain 
(e.g. GGSN or SGSN) and between the IM subsystem (CSCF) . 

25 

According to one of the preferred embodiments of the 
invention, the fourth network element such as the IP 
telephony layer is allowed to control at least one connection 
parameter, e.g. to restrict a PDP (Packet Data Protocol) 

30 context activation or modification. For example, a 

conversational PDP context, i.e., a connection enabling a 
conversation between the caller and the callee, may only be 
activated when the first network element, e.g. a mobile 
terminal, is trying to make a call to the second network 

35 element. When, as an example, the connection parameter is a 

PDP context, and an activation or modification of PDP context 
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is requested, the third network element such as a GGSN may 
send a permission request to the fourth network, such as CSCF 
or PCF or CPS, in order to check whether the PDP context 
activation or modification can be accepted. 

5 

This approach provides several advantages. First, the fourth 
network element such as CSCF learns the address of the third 
network element, e.g. the GGSN, from the request and 
therefore knows where to return the response. Otherwise, when 

10 the fourth network element were designed to send the 
information to the third network element before being 
addressed by the third network element, problems may arise 
when the fourth network element does not have information on 
the address of the third network element in charge of 

15 handling the connection. 

Even when the first network element, e.g. a mobile terminal, 
should directly send information to the fourth network 
element when trying to establish a connection such as a call, 

20 the first network element does not yet have information on 
the address of the third network element in charge of 
subsequently handling the connection, and can therefore not 
send this address information to the fourth network element. 
Furthermore, if a message such as an authorize message would 

25 first be sent from the fourth to the third network element, 
the third network element would have to store information on 
call handling parameters such as PDP contexts which are not 
yet active. The third network element might then have to 
activate a timer, and to remove the authorize information 

30 after timer expiry, in case the PDP context activation should 
not be performed for some reason. 

Furthermore, the solution proposed according to the present 
invention works also for roaming subscribers and thus 
35 provides additional advantage. 
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Generally, according to an aspect, the invention provides a 
-solution for restricting e.g. PDP context activation or 
modification based on a call that will be carried on the PDP 
context . 

5 

According to one of the preferred embodiments of the 
invention, a common identifier is provided in the networks or 
layers working according to different protocols, e.g. in the 
GPRS/UMTS layer and the IP telephony layer, as well as in a 
10 control means or function such as CSCF or PCF. This common 
identifier may be used to map a PDP context to a call. The 
common identifier may be e.g. a call identifier such as 
Call_Id already provided in SIP (Session Initiation Protocol) 
messages . 

15 

As an alternative, the common identifier may also be an 
identifier allocated in one of the layers, e.g. in the 
GPRS /UMTS layer. For instance, the common identifier in this 
case may be NSAPI. In this case, this common identifier is 

20 preferably sent to the fourth network element, e.g. the CSCF, 
in a protocol message such as the INVITE message of SIP. The 
common identifier (e.g. NSAPI) may then be sent from the 
third network element, e.g. GGSN, to the fourth network 
element (e.g. PCF) as well as from a fifth network element 

25 (e.g. CSCF) to the fourth network element. The fourth network 
element then maps a request (sent by the third network 
element) and an authorisation (sent by the fifth network 
element such- as CSCF) based on the common identifier, e.g. 
NSAPI . 

30 ; ! 

In accordance with a further preferred embodiment of the 
invention, a mechanism is provided for combining a connection 
parameter such as charging info generated in a first network 
such as mobile core network (e.g. SGSN and GGSN), and in 

35 another network such an IPT (IP-based telephony) core 
network, e.g. CPS. According to this embodiment, a 
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possibility for charging of QoS (Quality of Service) level 
used in telephony calls is provided. 

According to this aspect of the invention, a mechanism for 
5 combining the call-related charging info and for controlling 
relevancy between QoS reservation in the one network (e.g. 
IPT network, with IPT QoS reservation being sent e.g. in the 
INVITE message of SIP) and QoS reservation (e.g. PDP context 
QoS context activation) in the other network (e.g. mobile 
10 packet core network) is provided. As an example, the 

delivered identifier such as Call_Id is checked for charging 
purposes, and the requested QoS level relevancy or request is 
also checked both in the protocol message (e.g. SIP: INVITE) 
and PDP context activation message (s). 

15 

A new parameter may be introduced in PDP context activation 
for informing the third network element such as GGSN about 
the fourth network element such as serving CSCF, or 
integrated CSCF/PCF, or CPS. Therefore, the third network 
20 element is informed on the address of the fourth network 
element to which the QoS check request is to be sent. 

A further optional feature controllable by the end-user may 
be the possibility of requesting a QoS check by a terminal 
25 (e.g. first network element) in a protocol message such as 
SIP: INVITE. 

According to this aspect of the invention, the preparation of 
a charging record based on QoS provided is possible. 

30 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows the basic structure and message flow according 
35 to one embodiment of a method and system according to the 
invention; 
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Fig, 2 illustrates a further embodiment of a system and 
method in accordance with the present invention; 

5 Fig. 3 shows a further embodiment of a system and method in 
accordance with the present invention; 

Fig. 4 illustrates another embodiment of a system and method 
according to the present invention; 

10 

Fig. 5 shows another embodiment of a system and method in 
accordance with* the present invention; 

Fig- 6 illustrates a modification of the embodiment shown in 
15 Fig. 2; and 

Fig. 7 shows another embodiment of a system and method in 
accordance with the present invention 

20 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE 
INVENTION 

Fig. 1 illustrates a first embodiment of a method or system 
25 in accordance with the invention. This embodiment provides a 
CSCF-permitted PDP context activation or modification. A user 
equipment (UE) 1 is a first network element which may a 
mobile station. SGSN 2 represent a serving node (serving GPRS 
support node) which serves user equipment 1 in handling a 
30 connection to another network element (second network 

element) such as a terminal of a called party which is not 
shown in Fig. 1. GGSN (Gateway GPRS Support Node) 3 
represents a gateway node for handling connections to another 
network to which the called party terminal may be attached. A 
35 Call State Control Function (CSCF) 4 represents a fourth 
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network element which decides on permission of PDP context 
activation or modification . 

When the user equipment 1 intends to make a call to a 
5 terminal arranged in another network, e.g. an IP-based 

network, it sends a message such as an INVITE message of SIP 
(Session Initiation Protocol) to the CSCF 4. Thereafter, 
preferably after having received a response from CSCF 4 
informing on the acceptance of the call request, the user 
10 equipment 1 sends an Activate (or Modify) PDP context request 
to SGSN 2. The SGSN 2 in response to this Activate (or 
Modify) PDP context request, sends a Create (or Update) PDP 
context request to GGSN 3. 

15 In response to this request from SGSN 2, the GGSN 3 does not 
immediately perform a Create or Update of the PDP contexts 
but is adapted first to send a permission request to CSCF 4. 
In the embodiment of Fig. 1, the GGSN 3 sends this permission 
request to the CSCF 4 in order to check whether PDP context 

20 activation/modification can be accepted. In a modified 

embodiment, the permission request may also be sent to a 
policy control function PCF which may represent an additional 
optional network element or may be integrated with CSCF. 

25 The GGSN 3 includes IMSI/MSISDN (and possibly the PDP 

address) in the permission request to identify the mobile, 
that is the user equipment 1. The GGSN 3 may additionally 
send, in the permission request, the requested QoS (Quality 
of Service) values as well as the address of the called party 

30 (B Party Address) , if present in the traffic flow template 

TFT. If IMSI/MSISDN (and possibly PDP address) should not be 
sufficient to identify the user equipment 1 or the call, an 
additional information such as NSAPI may be used and 
transmitted to GGSN 3. In this case, the user equipment 1 

35 preferably sends the information NSAPI of the PDP context in 
a call-set up message to the CSCF, e.g. in the SIP: INVITE 



7 



WO 02/32165 



PCT/EPOO/09884 



message. The CSCF 4 (or if alternatively or additionally 
provided PCF) is then adapted to check that the NSAPI for the 
call contained in the call-set up message equals the NSAPI 
for the PDP context sent from the GGSN 3 in the permission 
request, so that the CSCF 4 (or the PCF) can authorise the 
correct PDP context. If there should be provided a separate 
PCF, the CSCF 4 is adapted to send the NSAPI to the PCF. 
Likewise, in this case, the GGSN 3 is adapted to send the 
permission request including NSAPI to the separate PCF. 

In response to the permission request and after effecting the 
above described check, the CSCF 4 (or the PCF) sends a 
permission response to the GGSN 3. The permission response 
includes IMSI/MSISDN for identifying the user equipment 1 or 
the call for which the PDP context is to be created or 
updated, and preferably additionally includes information 
such as "call characteristics". The call characteristics 
information preferably includes accepted QoS values, accepted 
B Party Information (preferably IP address and the port 
number of the called party) , as well as an indication 
indicating whether the call is a normal call or an emergency 
call. 

The GGSN 3 is adapted to set the QoS values to the ones 
received from the CSCF 4 (or the PCF) . The GGSN 3 can set the 
allocation/retention priority to the highest value if the 
call is an emergency call. Furthermore, the GGSN 3 can set 
the traffic flow template TFT according to the B Party 

Information. . . 

i 

In case the call is an emergency call and the PDP context is 
used for this emergency call, the user equipment 1 may be 
informed thereon by sending this information from the GGSN 3 
to the SGSN 2 which will forward this information to the 
(mobile) user equipment 1. 
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For sending the permission request, the GGSN * 3 must know the 
address of the CSCF 4 for communication. In one embodiment of 
the invention, the CSCF address is added as a new parameter 
to the Activate (or Modify) PDP context request and the 
5 Create (or Update) PDP context request messages. In an 

alternative embodiment, the GGSN 3 is implemented to derive 
the CSCF address from the TFT of the signalling PDP context* 

Further, the GGSN 3 may also be informed in some other way on 
10 the CSCF 4 address. 

When another network element such as PCF is provided for 
deciding on the permission, the address of this network 
element (such as PCF) may be configured to the GGSN 3 (per 
15 access point) and to the CSCF 4. 

Further, in accordance with another possible aspect of the 
invention, if the above described functionality (Permission 
Request and Permission Response) is also to be provided for 

20 roaming subscribers, a new parameter describing whether or 

not a permission from the CSCF (or the PCF) is needed at PDP 
context activation (or modification) , is added to the 
subscription information in the subscriber database (such as 
Home Location Register HLR) . This new parameter can be PDP 

25 context specific. 

Returning now to Fig. 1, after receipt of the Permission 
Response, the GGSN 3 sets the PDP context and further 
information as necessary in accordance with the information 

30 contained in the Permission Response, such as accepted QoS 
value etc. Further , the GGSN 3 returns a Create (or Update) 
PDP context response to SGSN 2. In response thereto, the SGSN 
2 sends an Activate (or Modify) PDP context response to the 
user equipment 1. Thereupon, the call is established and 

35 carried-out in the known manner. 
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Fig. 2 shows a further embodiment of the invention (method 
and/or system) which is provided with a Policy Control 
Function (PCF) . The PCF has an interface towards the GGSN as 
well as to the CSCF. The PCF can be used for the 
5 communication between the IP telephony layer, i.e. proxy 

CSCF, and the GPRS /UMTS layer (GGSN) . For example, a call can 
have effects on the PDP context which is activated for the 
call . 

Fig. 2 illustrates an example for the communication and 
message flow between the GPRS/UMTS layer, i.e. the GGSN, and 
the IP telephony layer, i.e. the CSCF, via the PCF. The IP 
telephony layer is allowed to restrict PDP context activation 
(or modification) . 

According to Fig. 2, a call-based permission for PDP context 
activation/modification is performed. The case shown presents 
a PDP context activation in case of a mobile originated (MO) 
call, that is a call originating from mobile station (MS) 21, 
the called party (callee) being represented by network 
element 27 (user equipment, database, etc.). For the PDP 
context activation, a permission is requested from the PCF 
25. Only the parameters required for the communication 
between proxy CSCF 26 and PCF 25, and for the communication 
between GGSN 24 and PCF 25 are shown and described below. 

Generally, according "to the embodiment shown in Fig. 2, a 
common identifier is provided in the GPRS/UMTS layer (i.e. 
GGSN 24 of third generation (3G)), in the IP telephony layer, 
30 e.g. CSCF 26, and in the PCF 25 for mapping a PpP f context to 
a call. The subscriber identifier, e.g. IMS I, is not enough 
when the MS 21 has multiple calls ongoing at the same time. 
In such a case, the common identifier used according to Fig- 
2, is the call identifier Call_Id which already exists in SIP 
35 messages. The initiator of a call, in the present example 
mobile station 21, allocates the Call_ Id in a manner known 

10 
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e.g. from SIP protocol which identifier Call_Id uniquely 
identifies the call. 

According to a preferred embodiment such as the one shown in 
5 Fig. 2, this common identifier such as Call_ Id is sent from 
the MS 21 to the SGSN 23 and from SGSN 23 to GGSN 24. 
Further, this common identifier is sent from the mobile 
station 21 to the proxy CSCF 26, preferably in a call- 
initiating message such as SIP: INVITE. Further, this common 

10 identifier is sent from the CSCF 26 to the PCF 25, and 

furthermore from the GGSN 24 to PCF 25. The PCF 25 then maps 
a request sent by the GGSN 24 and an authorisation sent by 
the CSCF 26 based on the common identifier (e.g. call Id), 
and decides on call permission and/or connection parameters 

15 such as QoS to be used. 

In a modified embodiment, an identifier allocated in the 
GPRS/UMTS layer, e.g. in the GGSN 24, is used as the common 
identifier. As an example, NSAPI is used as such a common 

20 identifier. In this case, in accordance with one embodiment 
of the invention, the NSAPI is sent from the MS 21 to the 
CSCF 26 in the INVITE message or other call-set up message. 
Furthermore, NSAPI is sent from the GGSN 24 to the PCF 25, 
and from the CSCF 26 to the PCF 25. In this case, the PCF 25 

25 maps a request sent by the GGSN 24 and an authorisation sent 
by the CSCF 26 based on NSAPI. 

An operator may configure access point specific information 
to the GGSN to indicate whether communication with the PCF is 
30 required and for what kinds of PDP context, e.g. only when 
the QoS class indicates conversational, i.e. a voice 
transmission. The PCF 25 address can also be configured to 
the GGSN 24 and to the CSCF 26 so that the GGSN 24 and the 
CSCF 26 can communicate with the same PCF 25. 

35 
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In an alternative ' embodiment, when the PCF address is not 
configured per network element such as elements 24 and 2 6, a 
new parameter, e.g. the PCF address, can be included in the 
subscription information in the subscriber database such as 
HLR and/or the UMS (User Mobility Server) . The SGSN 23 
receives the PCF 25 address from the subscriber database, 
e.g. HLR, and sends it to the GGSN 24. When receiving the PCF 
25 address, the GGSN 24 knows which PCF 25 to contact. The 
CSCF receives the same PCF 25 address from the UMS and can 
contact the same PCF 25. 

It may be home operator specific whether communication* with 
the PCF 25 is required or not. For roaming subscribers, a new 
parameter describing whether communication with the PCF 25 is 
required, e.g. an information "PCF Interaction Required" is 
added to subscription information in the subscriber database 
HLR and the UMS. The "PCF Interaction Required" in the HLR 
may be subscription specific or may be PDP context specific. 
The SGSN 23 receives the information "PCF Interaction 
Required" from the HLR and sends it to the GGSN 24. When 
receiving the information "PCF Interaction Required", the 
GGSN 24 knows whether it is necessary to communicate with the 
PCF or not when establishing a connection or modifying a 
connection or the like. The CSCF 26 receives the information 
"PCF Interaction Required" from the UMS and knows therefrom 
whether or not communication with the PCF 25 is required. 

Therefore, according to this aspect of the invention, three 
new ideas are alternatively or combinedly incorporated: 

(a) a common identifier is provided to map a PDP context to a 

call; : j 

(b) a new parameter for HLR and UMS is provided, namely the 
PCF address; and/or 

(c) a new HLR and UMS parameter is provided such as "PCF 
Interaction Required". 
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According to the embodiment of Fig. 2, the PS (Packet- 
switched) domain interaction with Policy Control Function 
(PCF) 25 is shown and described. The steps performed when 
establishing a connection are described below in more detail 
5 with reference to the step numbers shown in Fig. 2. 

In step 1., the mobile station 21 sends an INVITE message to ' 
the proxy CSCF 26, the INVITE message containing a subscriber 
identification "Subscriber Id" and a call identifier 
10 "Call_Id". The proxy CSCF 26 forwards this message to the 
callee 27. 

In step 2., the proxy CSCF 26 receives a positive 
acknowledgement from the callee terminal 27 , e.g. 183w/SDP as 
15 defined in SIP. The proxy CSCF 26 forwards this 

acknowledgement to the mobile station (caller) 21. 

In step 3., after receiving the positive acknowledgement from 
the callee terminal 27, the proxy CSCF 26 sends an authorise 

20 message (containing Subscriber Id, call identifier Call_Id, 
QoS negotiated, callee transport address) to the PCF 25. The 
Subscriber Id may e.g. be IMSI, MSISDN, or the IP address of 
the caller 21 (i.e. the PDP address in the GPRS/UMTS layer). 
The Call_Id is required and used to map the call to the 

25 correct PDP context in the PCF 25. The QoS negotiated 

includes the QoS parameters negotiated for the call. In case 
of an emergency call, the proxy CSCF 26 will set the QoS 
parameter allocation/retention priority to the highest value. 
The callee transport address is used in the GPRS /UMTS layer 

30 to set the TFT (Traffic Flow Template) for the PDP context. 

In step 4., the PCF 25 may acknowledge the authorise message 
of step 3. by returning an authorise acknowledge (Subscriber 
Id, Call_Id) message to the proxy CSCF 26. 

35 
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In step 5., the MS 21 requests to activate a PDP context 
(e.g. a secondary PDP context) for the call by sending an 
Activate (secondary) PDP context request (PDP address, 
Called, QoS Requested) message to the SGSN 23. 

5 

In step 6., a radio access bearer set-up procedure is 
performed. 

In step 7., the SGSN 24 sends a Create PDP context request 
10 (Subscriber Id, Call Id, QoS negotiated) message to the GGSN 
24. 

In step 8., the GGSN 24 requests permission for the PDP 
context activation by sending a Permission Request (Request 
15 Id, Subscriber Id, Call_Id, QoS negotiated) message to the 

PCF 25. The first request message (step 8.) creates a request 
state in the PCF 25. 

In step 9., the PCF 25 replies by sending a decision (Request 
20 Id, QoS negotiated, callee transport address) message to the 
GGSN 24. The GGSN 24 sets the TFT for the PDP context 
according to the callee transport address. 

In step 10., the GGSN 24 may report that it has acted in 
25 acccordance with the decision by sending a Report State 
message (Request Id) to the PCF 25. 

In steps 11., 12., the PDP context activation is reported in 
the known manner. 

30 i_ ' 

In Fig. 2, the messages 8 (request), 9 (decision), and 10 
(report state) are COPS messages. 

Fig. 2 illustrates the case of a PDP context activation. 
35 Steps 8. to 10. and the further steps shown in Fig. 2 are the 
same if the PDP context is to be modified. 
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It may be operator specific whether a permission for PDP 
context activation is required from the PCF 25. To provide 
this function also for roaming subscribers, a new parameter 
5 such as " PCF Interaction Required" is included in the 

subscription information in the HLR. The SGSN receives the 
"PCF Interaction Required" from the HLR and shall send it to 
the GGSN 24 at PDP context activation/modification. When 
receiving the "PCF Interaction Required", the GGSN 24 knows 
10 whether or not a communication with the PCF 25 is required 
when creating or modifying a PDP context. 

The GGSN 3, 24, 33 (Figs. 3 to 5) can know the address of 
CSCF 4, 26 (or CPS 34 of Figs. 3 to 5) 
15 by resolving the proxy CSCF address from the proxy CSCF 

domain name (preferred option) ; 

from a new parameter "CSCF address" sent by the MS in 
the (secondary) PDP context activation message; 
from the TFT of the signalling PDP context. 

20 

The parameters to be sent by the GGSN to find the right call 
or connection in the PCF (CPS; PCF is the logical element; It 
may be a standalone element or located either in the CSCF or 
in the GGSN. ) may be 
25 MS IP address (= PDP address) and MS port number (= TFT 

destination port number) (preferred option) ; 

Peer IP address (= TFT source address) and peer port 
number (= TFT source port number) . 



30 Figures 3 to 5 show further embodiments of the present 

invention which provide a method and mechanism to combine 
charging information generated by a mobile core network and 
an IPT core network. The mobile core network is represented 
by SGSN 32 and GGSN 33. The further necessary components for 

35 providing a mobile network are known to the skilled man and 
not shown in the drawings. The IPT core network is 

15 
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represented by Call Processing Server (CPS) 34. The further 
components of the IPT network are known to the skilled man 
and not illustrated in the drawings. 

5 The embodiments shown in the figures provide the possibility 
for charging of the QoS level used in telephony calls or 
connections of other type. As an example, telephony calls 
require real time (RT) traffic and usually necessitate higher 
QoS level than a communication of other type such as e-mail 
10 transmission (which may be transported using lower QoS level 
and thus being charged at a lower rate) . 

The embodiments shown in figures 3 to 5 provide a mechanism 
for combining call-related charging information and 
15 controlling relevancy or coincidence between IPT QoS 

reservation (e.g. as requested by the call originating 
terminal in e.g. SIP: INVITE message) and mobile packet core 
network PDP context QoS (PDP context activation) . 

20 Figures 3 to 5 show the message transmission between a mobile 
terminal (MT) 31 attached to the mobile network, SGSN 32, 
GGSN 33 (SGSN 32 and GGSN 33 forming part of the mobile 
network to which MT 31 is attached) , and Call Processing 
Server (CPS) 34. The CPS 34 comprises the Call State Control 

25 Function (CSCF) such as shown in figures 1 and 2 so that the 
inscription of block 34 may also be "CSCF". 

In the following, the embodiment shown in Fig. 3 will be 
described in more detail. 

30 

When the mobile terminal 31 wants to establish a connection 
to another network element such as a telecommunication 
equipment of a party to be called, the mobile terminal 31 
issues, as represented by step 1., a acaal establishment 
35 request such as an "INVITE" message of a Session Initiation 
Protocol such as SIP. The INVITE message is sent from MT 31 
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to CPS 34 and contains the information elements "Call_Id" and 
"SDP: QoS". SDP stands for Serving Profile DataBase. 
"Call_Id" represents a common identifier which is provided to 
allow to combine or otherwise benefit from links in charging 
5 data, e.g. CDRs (charging data records) generated by support 
nodes such as GSNs (GPRS support nodes) and CSCF (or CPS) . 
This common identifier, e.g. "Call_Id" is distributed in the 
connection establishment phase (e.g. call establishment 
phase) to the support nodes and CSCF (or CPS) . This technique 

10 is able to uniquely identify a connection or call to be 

established in all involved processing elements such as GGSN 
and CPS without requiring a direct interface between these 
components. This method and structure provides a mechanism 
for combining charging data and/or checking QoS validity in 

15 different network types which e.g. provide an all-IP- 
connection between end terminals, e.g. IP telephony. 

In a next step 2., the mobile terminal 31 transmits a PDP 
context activation request to the SGSN 32 which request not 

20 only includes the usual information such as bearer type and 
codec, but additionally the parameter "Call_ID". This 
parameter "Call_ID" and the further necessary known 
information elements are thereupon sent from SGSN 32 to GGSN 
33 so that GGSN 33 is also informed about the common 

25 identifier "Call_ID" attributed to the connection to be 
established. In a next step 3., the GGSN 33 sends a check 
request to CPS 34, the check request indicating the common 
identifier "Call_ID" and further information such as bearer 
type and codec. 

30 

As a next step 4., the CPS 34 (or CSCF contained in CPS 34) 
performs a check for the connection to be established as 
identified by the common identifier n Call_ID" and checks that 
the required QoS parameters are valid in both call signalling 
35 (SIP/SDP) and bearer (PDP contexts). The CSCF (CPS 34) 
performs this check for controlling the validity of the 
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required QoS parameters before accepting (or proceeding with) 
the call establishment so as to be able to charge for the QoS 
provided in the call or connection of other type, or for 
other purposes than charging. The CPS 34 issues OK or NOT OK 
5 as result of this check (Call_ID, SDP: QoS, bearer type, 

codec) and returns (step 5.) a response to GGSN 33 indicating 
the check result (okay/not okay) . The GGSN 33 uses the 
information received in step 5. for accepting (if check 
result is positive, "OK") or rejecting (if check result is 

10 negative, "N OK") the call-related PDP context activation, 

and returns a response to the SGSN 32 informing the latter on 
the acceptance or rejection of the PDP context activation (or 
modification) . The SGSN 32 performs the known steps upon 
receipt of the accept or reject response, and sends 

15 corresponding information to the mobile terminal 31. 

The CPS 34 (or CSCF) may also directly transmit a response to 
mobile terminal 31 (step 6.) returning a response to the call 
establishment request of step 1. As an example, a response 
20 • "OK/NOK" of SIP may be transmitted in step 6. 

Therefore, an additional message sequence between CSCF (or 
CPS) and GGSN 33 is provided for making a decision of how to 
proceed with a connection to be established. 

25 

The CPS (CSCF) 34 may also receive additional parameters in 
addition to "Call_ID" and base the decision on these 
additional parameters as well. 

30 The mechanism shown in Fig, 3 and described above is not 
restricted to QoS and charging aspects only but may also 
relate to checks or evaluations of other type. Furthermore, 
the decision made by CPS (CSCF) 34 may also be advisory and 
needs not be only a binary "OK/NOT OK" type. 

35 
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As shown in Figs, 3 to 5, the GGSN 33 is adapted to send the 
check request to the CPS (CSCF) 34 as step 3. Therefore, GGSN 
33 needs information on the address or name of CPS (CSCF) . In 
a case where the GGSN 33 has no knowledge about the serving 
5 CSCF (CPS 34) where the mobile terminal 31 has registered 
with the SIP registration mechanism and has sent the INVITE 
message, the GGSN 33 has to be informed on the address or 
name of this serving CSCF (CPS) 34. The embodiment of Fig. 4 
presents a solution to this problem. 

10 

In addition to the above discussed structure and function of 
the embodiment of Fig. 3, the embodiment of Fig. 4 provides a 
new parameter, e.g. "S-CSCF_logicalname" , in a PDP context 
activation request for informing GGSN 33 about the address or 
15 name of the serving CSCF (or CPS) 34 so that GGSN 33 knows 
where to send a "QoS check" request. 

The embodiment of Fig. 4 is based on the structure shown in 
Fig. 3 and described above. The above description also 
20 applies for the message sequences and performed steps as 
shown in Fig. 4. 

The mobile terminal 31 is informed on the CPS (or CSCF) 34 to 
which it has registered, and is adapted to include 

25 information on the address or name of the S-CSCF (Serving 

CSCF in CPS 34) in the message sent in step 2. to SGSN 32 and 
further transmitted to GGSN 33. This new parameter for 
indicating the address or name of the Serving CSCF is 
represented in Fig. 4, by the parameter "S-CSCF__logicalname" 

30 sent in the PDP context activation request. With this 

additional information "S-CSCF_logicalname", the GGSN 33 is 
now informed on the address or name of the correct CSCF 
(CPS), and sends the check request (step 3.) to the CPS 
(CSCF) 34 indicated by this parameter. The other steps shown 

35 in Fig. 4 are identical to same of Fig. 3 described above. 

19 
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Furthermore, Fig. 5 provides an additional optional feature 
controllable by an end-user of mobile terminal 31 allowing an 
end-user or call originating equipment to request a "QoS 
check", e.g. in a SIP: INVITE message. 

The embodiment according to Fig. 5 includes all features of 
the embodiments of figs. 3 and 4 described above. In 
addition, according Fig. 5, a new parameter, e.g. 
f, Require_ggsn_check", is included into the connection 
establishment request sent, in step 1., from mobile terminal 
31 to CPS (CSCF) 34. 

The structure and method shown in Fig. 5 is an addition to 
the combining mechanisms for charging data and QoS control as 
described and provided with regard to Figs. 3 and 4. The 
embodiment according to Fig. 5 allows an optional selection 
of performing or not performing the check steps 3. to 5. When 
the parameter "Require_ggsn_check" is set in the SIP INVITE 
message (or connection establishment request message of other 
appropriate type) sent from the mobile terminal 31 to CPS 34, 
the CPS (or CSCF included in CPS) is prepared to perform the 
check according to a step 4., and expects the check request 
message from GGSN 33 according to step 3. After receiving the 
check request in step 3., the CPS 34 performs the check of 
step 4. as described above, with the step sequence thereafter 
being continued as described above. When the parameter 
"Require_ggsn_check" is not set or not present in the 
connection establishment request of step 1., the CPS (CSCF) 
34 does not perform the QoS check according to step 4. and 
does not require any check message from GGSN 33. With this 
information provided by the new parameter 

"Require_ggsn_check", the CSCF is informed whether or not the 
check procedure is required to proceed with call 
establishment. The new check request parameter can of course 
have any arbitrary designation such as "Require_pdpqos_check" 
provided that it is understood by the CSCF . 
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This new parameter provided according to Fig. 5, and the 
optionality of performing or not performing a QoS check or 
check of any other type (step 4.) is also applicable with a 
5 structure as shown in Fig. 3 which does not provide the 

indication of the logical name or address of CPS 34 according 
to step 2. of Fig. 4. In particular in a case where the GGSN 
33 is informed by other means on the address of CPS 34 to 
which MT 31 is registered, e.g. by sending a message from CPS 
10 34 to GGSN 33. 

The methods and mechanisms provided according to the 
embodiments of the invention may be implemented as software 
in GGSN 3, 33 and/or CSCF / CPS 34 allowing a proper 
15 execution of the requests and checks as well as check result 
processing and charging information generation for providing 
a charging record for established connections. 

The provided method and mechanism for checking QoS parameters 
20 may also be implemented separately from charging information 
generation. 

The shown embodiments furthermore provide the possibility of 
controlling and inhibiting e.g. PDP context update for PDP 
25 contexts allocated for voice calls until a check from CPS 34 
is performed. This can be managed by providing another 
message exchange between GGSN 33 and CPS 34. 

Fig. 6 shows a further embodiment of the invention (method 
30 and/or system) which is a modification of the embodiment 

shown in Fig. 2. According to Fig. 6, the PCF 25 (Fig. 2) is 
integrated with the Proxy CSCF 2 6 (Fig. 2) and forms a single 
network element 25'. This structure provides the benefit of 
avoiding any external signalling between the PCF and CSCF so 
35 that the steps 3. and 4. of Fig. 2 can be omitted. The 

authorization check according to these steps 3., 4. of Fig. 2 
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is performed using internal processing within network element 
25' of Fig. 6. The signalling between PCF and CSCF is in this 
case merely an internal signalling (i.e. not so strictly 
limited by any standardization) . 

5 

The further steps 1., 2., and 5. to 12. of Fig. 6 are 
identical to the ones described above with regard to Fig. 2. 

The PCF may therefore be a separate logical entity 25 as 
10 shown in Fig. 2, may be integrated to the CSCF as shown in 
Fig. 6, or may also be integrated to the GGSN 24. 

Fig. 7 shows another embodiment of a system and method in 
accordance with the present invention which provides a call- 

15 based PDP context activation / modification. Fig. 7 presents 
a PDP context activation in case of a MO call. It is assumed 
that at least one PDP context is activated for the call. For 
the PDP context activation, a permission is requested from 
the PCF. The permission from the PCF is required to adjust 

20 the QoS of the PDP context to the QoS of the call. 

It could be configured to the GGSN whether a decision is 
needed from the PCF and for what kind of PDP contexts. As an 
example, the configuration information can define that a 
decision from the PCF is needed only for conversational PDP 

25 contexts, while for other PDP contexts, the PDP context 
activation shall proceed without PCF interaction. 
Only the parameters which are required for the GGSN - PCF 
communication are shown and described below. In the following, 
the steps shown in Fig. 7 will be described in detail. 

30 i j 

Step 1. The MS sends the Invite (Subscriber Id) message 
to the proxy CSCF. The proxy CSCF forwards the message 
towards the callee. 

Step 2. The proxy CSCF receives a positive 
35 acknowledgement, e.g. 183 w/SDP. The proxy CSCF forwards the 
acknowledgement to the caller. 
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Step 3- The MS activates a PDP context for the call by 
sending the Activate Secondary PDP Context Request (QoS 
Requested) message to the SGSN. 

Step 4. The radio access bearer setup procedure is 
performed. 

Step 5. The SGSN sends the Create PDP Context Request 
(PDP Address, QoS Negotiated) message to the GGSN. 

Step 6. The GGSN requests permission for the PDP context 
activation by sending the Request (Request Id, Subscriber Id, 
QoS Negotiated) message to the PCF. The Subscriber Id is an 
identifier known both in the PS domain and in the IM 
subsystem, e.g., the IP address of the MS. 

Step 7. The PCF replies by sending the Decision 
(Request Id, QoS Negotiated) message to the GGSN. 

Steps 8.-9. The PDP context activation is accepted with 
the parameters received from the PCF. 

Step 10. The GGSN may report that it has successfully 
completed performing the decision by sending the Report State 
(Request Id) message to the PCF. 

The steps 6, 7 and 10 are the same if the PDP context is 
modified. 

Although preferred embodiments have been shown and described 
above, the invention is not limited to the details described 
and shown and intends to cover all modifications, omissions, 
and additions of the features described above and shown in 
the drawings. 

As an example, the invention is not limited to a 
communication between GGSN (3, 24) and PCF - CSCF (or 
CSCF/PCF) . The same communication is .possible by replacing 
the GGSN 3, 24 with the SGSN 2, 23, resulting in SGSN - PCF - 
CSCF (or CSCF/PCF) communication. 
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CLAIMS 

5 



1. Method for establishing or handling a connection 
between a first and a second network element connected to 

10 different networks, the connection being established by means 
of at least one third network element arranged in one of the 
networks, wherein the third network element, when receiving 
information on an establishment of a connection, sends a 
request to a fourth network element, the request requesting 

15 permission for establishing a requested type of* connection, 
or requesting a check of a connection parameter, the request 
specifying the first and/or second network element and/or the 
connection or connection type to be established, the fourth 
network element returning a response specifying a permission 

20 for establishing a connection or connection type, or 

specifying a connection parameter, the establishment or 
handling of the connection being controlled in dependence on 
the response. 

25 2, Method according to claim 1, wherein the third 

network element is a support node. 

3. Method according to claim 2, wherein the support node 
is a gateway node, in particular a GGSN (Gateway GPRS Support 
Node) . ; / 

4. Method according to any one of the preceding claims, 
wherein the fourth network element is a Call State Control 
Function (CSCF) . 

5. Method according to any one of the preceding claims, 

24 
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wherein the fourth network element is a Policy Control 
Function (PCF) . 

6. Method according to any one of the preceding claims , 
5 wherein the fourth network element is a Call Processing 

Server (CPS) . 

7. Method according to any one of the preceding claims , 
wherein the fourth network element is at least partly 

10 implemented as part of the third network element. 

8. Method according to any one of the preceding claims , 
wherein the request is a permission request requesting 
permission to activate or modify a PDP Context for the first 

15 and/or second network element. 

9. Method according to any one of the preceding claims, 
wherein the request is a check request requesting a check of 
at least one connection parameter. 

20 

10. Method according to any one of the preceding claims, 
wherein the response indicates call characteristics, 
preferably accepted QoS values, and/or accepted information 
on the second network element, and/or an indication 

25 indicating whether the connection is a normal call or an 
emergency call. 

11. Method according to any one of the preceding claims, 
wherein the first network element addresses a fifth network 

30 element when trying to establish a call, the fifth network 
element sending an authorization message to the fourth 
network element characterizing at least one call parameter, 
the fourth network element forming its response to the third 
network element based on the contents of the authorization 

35 message. 
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12. Method according to any one of the preceding claims, 
wherein subscription information stored for the first network 
element includes a parameter defining the necessity of 
sending a request from the third to the fourth network 

5 element when establishing a connection between the first and 
second network element, this parameter being sent to the 
third network element when establishing a connection between 
the first and second network element, the third network 
element deciding on the necessity of sending the request to 
10 the fourth network element depending on the contents of this 
parameter. 

13. Method according to claim 12, wherein, when the 
parameter indicates no necessity for sending a request from 

15 the third to the fourth network element, the third network 
element does not send such a request and proceeds with the 
establishing of the connection between the first and second 
network elements. 

20 14. Method according to any one of the preceding claims, 

wherein a common identifier is provided for identifying a 
network element requesting the establishment to another 
network element, or for identifying a call, both in an IP- 
based network and an GPRS- or UMTS-based network. 

25 

15, Method according to claim 14, wherein the common 
identifier is used for mapping connection parameter, in 
particular PDP Context information, to a call, and is 
transmitted to both the third and the fourth network element 
30 when establishing a connection between the first and second 
network element. 



16. Method according to claim 14 or 15, wherein the 
common identifier is NSAPI, or a Call Identifier provided in 
35 a connection initiating protocol, preferably SIP (Session 
Intitiation Protocol) . 

26 



17, Method according to any one of the preceding claims, 
wherein an address of the fourth network element is contained 
in subscription information stored for the first network 

5 element, the address being transmitted to the third network 
element when establishing a connection being the first and 
second network element. 

18. Method according to any one of the preceding claims, 
10 wherein a charging record for charging for the connection is 

provided taking account of the result of a check of the 
connection parameter. 



19. Method according to any one of the preceding claims, 
15 wherein the connection parameter indicates requested or 

accepted QoS, and the QoS information provided in both the 
signalling and user traffic is checked, a charging record 
being provided taking account of the check result. 

20 20. Method according to claim 19, wherein the QoS check 

is effected in response to a check request. 

21. Method according to any one of the preceding claims, 
wherein the connection parameter indicates call 
25 characteristics, preferably accepted QoS values, and/or 
information about the second network element, and/or an 
indication indicating whether the connection is a normal call 
or an emergency call. 



30 22. Method according to any one of the preceding claims, 

wherein the connection involves at least two networks of 
different types, preferably a GPRS/UMTS-based network and an 
IP-based network, and QoS values provided provided in both 
networks for the connection are checked and compared for 

35 gaining charging-related information. 
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23. Method according to any one of the preceding claims, 
wherein a check request for checking a charging-related 
parameter is sent from the first network element to the 
fourth or another network element when sending a call 

5 establishment request. 

24. System for establishing or handling a connection 
between a first and a second network element connected to 
different networks, the connection being established by means 

10 of at least one third network element arranged in one of the 
networks, wherein the third network element is adapted to 
send, when receiving information on an establishment of a 
connection, a request to a fourth network element, the 
request requesting permission for establishing a requested 

15 type of connection, or requesting a check of a connection 
parameter, the request specifying the first and/or second 
network element and/or the connection or connection type to 
be 'established, the fourth network element returning a 
response specifying a permission for establishing a 

20 connection or connection type, or specifying a connection 
parameter, the establishment or handling of the connection 
being controlled in dependence on the response. 

25. System according to claim 24, wherein the third 
25 network element is a support node. 

26. System according to claim 25, wherein the support 
node is a gateway node, in particular a GGSN (Gateway GPRS 
Support Node) . 

30 } 

27. System according to any one of the preceding system 
claims, wherein the fourth network element is a Call State 
Control Function (CSCF) . 
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28. System according to any one of the preceding system 
claims, wherein the fourth network element is a Policy 
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Control Function (PCF) . 

29. System according to any one of the preceding system 
claims, wherein the fourth network element is a Call 
Processing Server (CPS) . 

30. System according to any one of the preceding system 
claims, wherein the fourth network element is at least partly 
implemented as part of the third network element. 

31. System according to any one of the preceding system 
claims, wherein the request is a permission request 
requesting permission to activate or modify a PDP Context for 
the first and/or second network element. 

32. System according to any one of the preceding system 
claims, wherein the request is a check request requesting a 
check of at least one connection parameter. 

33. System according to any one of the preceding system 
claims, wherein the response indicates call characteristics, 
preferably accepted QoS values, and/or accepted information 
on the second network element, and/or an indication 
indicating whether the connection is a normal call or an 
emergency call. 

34. System according to any one of the preceding system 
claims, wherein the first network element is adapted to 
address a fifth network element when trying to establish a 
call, the fifth network element being adapted to send an 
authorization message to the fourth network element 
characterizing at least one call parameter, the fourth 
network element being adapted to form its response to the 
third network element based on the contents of the 
authorization message. 
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35. System according to any one of the preceding system 
claims, wherein subscription information stored for the first 
network element includes a parameter defining the necessity 
of sending a request from the third to the fourth network 
5 element when establishing a connection between the first and 
second network element, this parameter being sent to the 
third network element when establishing a connection between 
the first and second network element, the third network 
element being adapted to decide on the necessity of sending 
10 the request to the fourth network element depending on the 
contents of this parameter. 



36. System according to claim 35, wherein, when the 
parameter indicates ^no necessity for sending a request from 
15 the third to the fourth network element, the third network 
element does not send such a request and proceeds with the 
establishing of the connection between the first and second 
network elements. 



20 37. System according to any one of the preceding system 

claims, wherein a common identifier is provided for 
identifying a network element requesting the establishment to 
another network element, or for identifying a call, both in 
an IP-based network and an GPRS- or UMTS-based network. 

25 

38. System according to claim 37, wherein the common 
identifier is used for mapping connection parameter, in 
particular' PDP Context information, to a call, and is 
transmitted to both the third and the fourth network element 
30 when establishing a connection between the first and second 
network element. 



39. System according to claim 37 or 38, wherein the 
common identifier is NSAPI, or a Call Identifier provided in 
35 a connection initiating protocol, preferably SIP (Session 
Intitiation Protocol) . 
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40. System according to any one of the preceding system 
claims , wherein an address of the fourth network element is 
contained in subscription information stored for the first 
network element, the address being transmittable to the third 
network element when establishing a connection being the 
first and second network element. 

41. System according to any one of the preceding system 
claims, wherein a charging record for charging for the 
connection is provided taking account of the result of a 
check of the connection parameter. 

42. System according to any one of the preceding system 
claims, wherein the connection parameter indicates requested 
or accepted QoS, and the QoS information provided in both the 
signalling and user traffic is checked, a charging record 
being provided taking account of the check result. 

43. System according to claim 42, wherein the QoS check 
is effected in response to a check request. 

44. System according to any one of the preceding system 
claims, wherein the connection parameter indicates call 
characteristics, preferably accepted QoS values, and/or 
information about the second network element, and/or an 
indication indicating whether the connection is a normal call 
or an emergency call . 

45. System according to any one of the preceding system 
claims, wherein the connection involves at least two networks 
of different types, preferably a GPRS/UMTS-based network and 
an IP-based network, and QoS values provided provided in both 
networks for the connection are checked and compared for 
gaining charging-related information . 
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4 6. System according to any one of the preceding system 
claims , wherein a check request for checking a charging- 
related parameter is sent from the first network element to 
the fourth or another network element when sending a call 
establishment request . 

47. A method for establishing a connection in a two- 
layer communication network comprising a first communication 
network layer adapted to establish a communication channel to 
a terminal and a second communication network layer adapted 
to establish a session carried on said communication channel, 
said method comprising the steps of: 

establishing a session with an identifier, 
establishing a communication channel with said 
identifier, 

authorizing said communication channel by said session 
using said identifier. 

48. Method according to claim 47, wherein said 
authorizing comprises the steps of: 

a network element in said first communication network 
layer (e.g. GGSN) initiating a request for said authorization 
at communication channel establishment 

a network element in said second communication network 
layer (e.g. CSCF) performing said authorization. 

49. Method according to claim 4 7 or 48, wherein said 
first communication network layer is a GPRS/UMTS layer, and 
said second communication network layer is an IP Multimedia 
Subsystem. f • 

50. Method according to claim 47, 48, or 49, wherein 
said terminal is a User equipment or Mobile Station. 

51. A system for establishing a connection in a two- 
layer communication network comprising a first communication 
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network layer adapted to establish a communication channel to 
a terminal and a second communication network layer adapted 
to establish a session carried on said communication channel , 
said system being adapted: 

to establish a session with an identifier, 
to establish a communication channel with said 
identifier, 

to authorize said communication channel by said session 
using said identifier. 

52. System according to claim 51, wherein for performing 
said authorizing: 

a network element in said first communication network 
layer is adapted to initiate a request for said authorization 
at communication channel establishment 

a network element in said second communication network 
layer is adapted to perform said authorization. 

53. System according to claim 51 or 52, wherein said 
first communication network layer is a GPRS/UMTS layer, and 
said second communication network layer is an IP Multimedia 
Subsystem. 

54. System according to claim 51, 52, or 53, wherein 
said terminal is a User equipment or Mobile Station. 
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